The present invention relates to a memory management method which dynamically secures and releases a memory of a computer, and a computer using the same.
It has been known that securing and releasing processing of a memory area used by a program when a computer program is developed is apt to cause a problem with a program such as a false area reference. Particularly, in a program development by plural persons or large-scale program development, it is becoming difficult to completely grasp securing and releasing processing of all memories.
To solve this problem, there is used a garbage collector for automating memory management in a program. Java (a registered trademark of Sun Microsystems, Inc. in the USA), which is one of language processors equipped with a memory management function using a garbage collector, prepares for an Application Program Interface (API, description for programming) but has no API for release. That is to say, a Java program developer needs to specify (describe) the securement of a memory area but does not need to describe the release processing of the memory area. The memory area secured in the process of executing a program is released by the garbage collector implemented in a Java virtual machine executing a program and the released area is reusable. A function executed by the garbage collector is garbage collection (hereinafter referred to as GC). In other words, the term GC refers to a function to collect (delete) unnecessary data out of the memory area dynamically secured by a program (during execution) and release the area where the unnecessary data is collected.
In a commonly used GC method, all Java program execution threads are stopped to collect unnecessary data. The Java virtual machine starts the garbage collector when the amount of use of a Java heap memory (hereinafter referred to as Java heap) which stores data (object) generated by a program exceeds a certain threshold.
In recent years, a Java system executing a program described by the Java language on a Java virtual machine has been used in an embedded system such as a server system, a cellular phone and a car navigation system. These systems have a problem in that the stoppage of the Java program execution thread by the GC lowers the response performance of the system.
A method of solving this problem is disclosed in Angelo Corsaro and Ron K. Cytron, Efficient Memory-Reference Checks for Real-time Java, Proceedings of the 2003 Conference on Languages, Compilers, and Tools for Embedded Systems, 2003 as well as in F. Pizlo, J. M. Fox, D. Holmes and J. Vitek, Real-Time Java Scoped Memory: Design Patterns and Semantics, Proceedings of the Seventh IEEE Internal Symposium on Object-Oriented Real-Time Distributed Computing, 2004. The methods disclosed in these documents have not only a heap memory (Java heap) subjected to the GC by the Java virtual machine, but also a heap memory (hereinafter referred to as external heap memory) not subjected to the GC. The term external heap memory refers to a memory area where a memory can be managed by a program. In other words, the securement of a memory area from the external heap memory, the generation of an object and the release of the memory area follow the description of a program into a source code by a programmer. In the release processing of memory area of the external heap memory, a referential relationship of an object generated in the secured memory area is restricted to release the memory area irrespective of an object generated in the memory area. The restriction ensures that, when an object generating thread is reduced to zero in a certain memory area in the external heap memory, the release of the memory area does not influence the execution of the program. Thus, the referential relationship of the object is restricted using an area where a memory area can be managed by a program, i.e., using the external heap memory not subjected to the GC by the Java virtual machine to minimize the occurrence of halt of the Java program execution thread for a long time.
The restrictive items on the referential relationship between the objects in the methods disclosed in the Angelo Corsaro and Ron K. Cytron as well as in the F. Pizlo, J. M. Fox, D. Holmes and J. Vitek significantly impair the convenience of this memory area. Specifically, one or more threads need to execute an interval generating an object on a memory area as a condition for the existence of the memory area of the external heap memory secured during the execution of the program; however, the condition imposes tight restrictions on the programming. Since the referential relationship between objects is restricted, the programmer needs to perform programming while always paying attention to the restriction; however, it is extremely difficult to grasp the referential relationship between objects because the program becomes large in scale and implicit data which is not described in a user program is generated. If the referential relationship against the restrictions is detected by a check at the time of executing the program, an exception occurs, which may not normally execute the program.
To solve such a problem, when a certain memory area in the external heap memory is released without imposing restrictions on the referential relationship between objects, a relationship between an object in the memory area to be released and an object in the other areas (the Java heap subjected to the GC and the memory area not subjected to the release of the external heap memory) is checked to confirm that the release of the memory area does not disturb the execution of the program, and then the memory area is released.
The check of the referential relationship between objects requires processing time depending on the number of objects included in the Java heap and the external heap memory. In general, the larger the capacity of the Java heap and the external heap memory, the greater the number of objects included therein, so that a system with a large capacity memory requires a long processing time to safely release a memory.